Reengineering with Reflexion Models: A Case Study

T o effectively perform most software engineering tasks on an existing system, a software engineer must have some understanding of the system's source code. However, gaining insight into the source code of large and complex systems typically takes too long and costs too much. In an attempt to address this problem, we developed the software reflexion model technique, 1 which lets software engineers rapidly and cost-effectively gain task-specific knowledge about a system's source code. In this article we give an overview of our technique and then relate how a Microsoft engineer used it to aid an experimental reengineering of Excel—a product that comprises about 1.2 million lines of C code. Our technique begins with a high-level model, which users define on the basis of a desired software engineering task. We had often seen software engineers use an informal structural model, say sketched on a white board, to begin reasoning about systems. However, reasoning about a task in this way carries significant risk because the model is disconnected from the source. Thus, the next steps in our technique are to extract a model of the source, define a map, and, through a set of computation tools, compare the two models. This lets software engineers effectively validate their high-level reasoning with information from the source code. To satisfy the need for a quick and inexpensive method, we made the technique " lightweight " and iterative. The user can easily and rapidly access the structural information of interest and can balance the cost of refinement with the potential benefits of a more complete and accurate model. The engineer in our case study—a developer with 10-plus years at Microsoft— specified and computed an initial reflexion model of Excel in a day and then spent four weeks iteratively refining it. He estimated that gaining the same degree of familiarity with the Excel source code might have taken up to two years with other available approaches. The case study demonstrates not only that our technique and tools can scale up to large real-world problems , but also that our technique is flexible and robust enough to withstand adaptations to suit a particular task or environment.